Many online applications are required to provide confidential information to their users and require a high degree of confidence that the user is actually entitled to receive back the confidential information. For example, for investment firms that provide investment information to users over the internet, it is crucial to know that the user is actually entitled to confidential financial information.
When a user goes to a URL via a web browser to log into an online domain (e.g., an application), the user is typically presented a request to enter login credentials (e.g., a user name, a password and/or user defined answers to questions). The login credentials can be sent to a server, validated, and then the server can transmit a login cookie that includes the user's login credentials back to the user's computer. The user's browser stores the cookie, and presents the login cookie when the user requests access to resources within the domain that created the login cookie. During the user's session, each time the user requests access to a protected resource, the login cookie is presented to an access point of the protected resource. The access point ensures that the user is authorized to gain access to the protected resource by checking the login credentials in the cookie.
An illegitimate user looking to gain access to the protected resource and protected information associated with the user can hack into the user's session and steel the user's login cookie. Once the illegitimate user has the user's login cookie, the illegitimate user can use the login cookie to obtain all of the information and enter all protected resources that the legitimate user has access to.
Login cookies can be stolen by illegitimate users (e.g., hackers, attackers, and/or malicious insiders) in a variety of ways. Illegitimate users having access to any server operating within a particular login domain can gain access to the cookies being sent to servers within the login domain. The servers can include servers internal to the login domain and/or servers hosted by a third party included in the domain. Many third party hosted servers within the login domain and/or servers hosting client customizable sites within the login domain can have lower levels of security assurance then servers internal of the login domain
For example, hackers can user cross-site scripting. When present on a website, the hacker can take advantage of the cross-site scripting by sending a maliciously constructed spam email to entice a user to click on the email. When the user clicks on the email, its contents execute inside the user's browser to transmit the user's login cookie to the hacker.
In other example, hackers can use third party sites that interact with the protected resources, user sites that are customized for a particular customer, impersonate protected resources, and/or enter a mix of secured/non-secure content where some sites are not enabled on SSL where attacks could be launched with tools like SSL strip to gain access to protected resources.
One current method of preventing stealing of login cookies involves increasing security of sites that receive cookies. However, for domains that require transmission of cookies to sites outside of the domain's control (e.g., sites are hosted by third-parties, or when permissions are granted to clients to update the sites) it can be difficult to implement increased security.
Another current method of preventing stealing of cookies is to ensure that pages sent to clients do not present opportunities for exploitation. However, this method can be impractical as new exploits are typically discovered by attackers every day and the amount of pages normally needed in support any site makes it difficult to stay ahead of attackers.
Another current method of preventing stealing of cookies is to ensure that all clients run security software to prevent malicious software from being installed on their equipment. However, it can be very difficult to mandate and ensure that all client users have the security software installed and running and even if the security software is running there is no guarantee that the security software catches all Trojans before they are installed.
Another current method of preventing stealing cookies is to educate customers not to click links in dubious e-mails and/or visit dubious sites. It can be very difficult to reliably train clients/customer to avoid these situations.
Another current method of preventing stealing of cookies is to set the timeout value low enough to be effective against attackers, but not to inhibit real customers from conducting their business.
Therefore, it is desirable to prevent cookies from being stolen in a manner that requires no change to the client device, no training of the user, and/or other impacts to the client device. It is desirable to prevent cookies from being stolen in a manner that has minimal impacts on access points of the protected resources. It is also desirable to provide continuous validation that the user issued the login cookie at the initial logon is the same user presenting the cookie on subsequent requests.